1. Technical Field
This disclosure relates generally to application security and, in particular, to a method to enable a user to authenticate to a remote server application seamlessly from within a rich client.
2. Background of the Related Art
It is known in the prior art to integrate Web- or cloud-based applications with so-called “rich” clients, where a “rich” client is a client (of a client-server application) that supports its own interface (as opposed to merely exporting the web interface from the web application itself). A “rich” client typically is not browser-based, and it is sometimes referred to as a “thick” (as compared to a browser-based or “thin”) client. An illustrative rich client is Lotus Notes®, which provides email, calendaring, contact management, and instant messaging. A rich client can be used to access and automatically perform actions on behalf of a user.
To enable access to data from a variety of applications, the first issue to be resolved is user authentication. If a user uses a desktop application to access the data on a remote server and then switches to another application, e.g., a browser, the authentication information associated with the session does not transfer easily from the desktop application to the browser, even though these applications run on the same machine Currently, the transition of authentication information from a desktop application to a browser (and for a Microsoft Windows based desktop) is done via SPNEGO (Simple and Protected GSSAPI Negotiation mechanism). Implementing such technologies, however, is a major barrier to entry for most enterprises. As a consequence, it is often necessary for passwords to be stored and maintained in multiple locations, which is undesirable from a security perspective. In addition, not all deployments just offer basic authentication; the problem of sharing a user's authentication information thus must also take into consideration those deployments that may be protected via a variety of alternative authentication mechanisms that the desktop application also has to understand if it is share the user's information appropriately and securely. These requirements can impact the adoption rate for the application and/or complicate its usage.
The problem of how to share a user's authentication information across local applications also exists for products that have desktop applications that ship along with a browser-accessible server. One known solution enables authentication of a rich client from within an existing browser session. In that approach, a user authenticates to a Web- or cloud-based application from a browser-based client. The browser-based client has an associated rich client. After a session is initiated from the browser-based client (and a credential obtained), the user can discover that the rich client is available and cause it to obtain the credential (or a new one) for use in authenticating the user to the application (using the rich client) automatically, i.e., without additional user input. An application interface provides the user with a display by which the user can configure the rich client authentication operation, such as specifying whether the rich client should be authenticated automatically if it detected as running, whether and what extent access to the application by the rich client is to be restricted, if and when access to the application by the rich client is to be revoked, and the like.
Although the above-described approach provides significant benefits, it may not be possible to include the rich client control panel UI or otherwise assume that the user starts from within a web browser session.